Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUGFIX beta] Add warning for “deep @each” usage in dependent keys #12847

Merged
merged 1 commit into from
Jan 21, 2016

Conversation

jgwhite
Copy link
Contributor

@jgwhite jgwhite commented Jan 20, 2016

Adds a warning when defining dependent keys of the form [email protected] or [email protected][email protected] as described in the guides.

Fixes #12840.

@stefanpenner
Copy link
Member

r? @rwjblue @krisselden

@rwjblue
Copy link
Member

rwjblue commented Jan 20, 2016

LGTM

@rwjblue
Copy link
Member

rwjblue commented Jan 20, 2016

Can you rebase?

@homu
Copy link
Contributor

homu commented Jan 20, 2016

☔ The latest upstream changes (presumably #12848) made this pull request unmergeable. Please resolve the merge conflicts.

@@ -257,6 +257,12 @@ ComputedPropertyPrototype.property = function() {
`Please refactor from \`Ember.computed('${property}', function() {});\` to \`Ember.computed('${property.slice(0, -6)}.[]', function() {})\`.`,
property.slice(-5) !== '@each'
);
warn(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should it not be an assertion? also, should we say the workaround is to create an intermediary computed property?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If its an assertion it may break people's apps who are using it today without knowing that it doesn't work. 👍 for suggesting an intermediate CP in the meantime.

@krisselden
Copy link
Contributor

Other than I think we should consider it an error since it doesn't actually work to do this, this looks good to me.

@stefanpenner
Copy link
Member

I don't think it can be an error until it's deprecated, etc. even though it doesn't work as expected. Would cause mega emo for little win.

@jgwhite
Copy link
Contributor Author

jgwhite commented Jan 21, 2016

Rebased and applied @krisselden and @mmun suggestions.

rwjblue added a commit that referenced this pull request Jan 21, 2016
[BUGFIX beta] Add warning for “deep @each” usage in dependent keys
@rwjblue rwjblue merged commit 0a36691 into emberjs:master Jan 21, 2016
@rwjblue
Copy link
Member

rwjblue commented Jan 21, 2016

Thanks @jgwhite!

@jgwhite
Copy link
Contributor Author

jgwhite commented Jan 21, 2016

<3

@barneywilliams
Copy link

Thanks much for this patch! It has cost us many hours and bugs, and we are still concerned that it would be popping up from time to time.

Although, I think that an error would be more appropriate than a warning... since it doesn't even work. But this is great for starters...

The user base would MUCH appreciate if these dependency variants could actually be supported. Is this being considered?

@jgwhite jgwhite deleted the deep-each-warning branch January 21, 2016 14:31
@stefanpenner
Copy link
Member

@barneywilliams it would require a champion, I don't believe anyone currently is. Maybe someday

@barneywilliams
Copy link

@stefanpenner Fully understand and agree. Maybe I can carve out the motivation to investigate and maybe take a stab at it some night or weekend...

@rwjblue
Copy link
Member

rwjblue commented Jan 21, 2016

FWIW, I think we all generally agree that we would like [email protected] to work and just haven't had the time to tackle it.

I'm not really sold on making [email protected][email protected] work though...

@stefanpenner
Copy link
Member

I'm not really sold on making [email protected][email protected] work though...

Ya, its possible but ends up being quite costly to maintain. Maybe after/while the next push on chains/references happens.

@barneywilliams
Copy link

Thanks for the feedback guys. I have another co-worker/ember-dev that is willing to pitch in as well, so maybe we can actually make this happen.

I agree/understand the additional complexities with nested @eaches that may be difficult to maintain.

I am going to file a request and link back to this post (for reference). Maybe we can drum up more support there as well.

@cibernox
Copy link
Contributor

This will warn also on hidden usages of this like computed.filterBy("array","state.isActive",true)?

@jgwhite
Copy link
Contributor Author

jgwhite commented Jan 22, 2016

@cibernox looks like the array macros use computed(dependentKey, ...) so yeah, should be good.

@jgwhite
Copy link
Contributor Author

jgwhite commented Jan 25, 2016

This patch also warns for dep keys of the form [email protected].[]. I take it this case is also unsupported?

/cc @stefanpenner @rwjblue

@runspired
Copy link
Contributor

@barneywilliams all of those situations are accomplishable with two computed properties. It's possible if you need it enough to write a computed property of your own that generates the necessary first step computed for you. Not sure how well it would perform, but would cut down some boiler plate from time to time.

@barneywilliams
Copy link

Chris, that is a good thing to point out on this thread. That coupled with the new warning is definitely buttons it all up better and may be a decent place to settle.

Aesthetically, it bugs me to write CPs that are only used internally, especially to work around limitations.

Although, Ember is very powerful as it is and am glad there are solutions, albeit workarounds, for these limitations.

On Feb 4, 2016, at 5:33 PM, Chris Thoburn [email protected] wrote:

@barneywilliams all of those situations are accomplishable with two computed properties. It's possible if you need it enough to write a computed property of your own that generates the necessary first step computed for you. Not sure how well it would perform, but would cut down some boiler plate from time to time.


Reply to this email directly or view it on GitHub.

@Serabe
Copy link
Member

Serabe commented Mar 28, 2016

Actually interested on the last case @jgwhite explained. I have a hierarchy of classes and I use some CP's coming from a flat-map operation.

I have a class A that has many class B that has many class C. Then:

const C = Ember.Object.extend({
  prop: Ember.computed(/* something that resolves to an array */)
});

const B = Ember.Object.extend({
  cs: collectionOfInstancesOfC,
  prop: Ember.computed(
    '[email protected].[]',
    function() { flatMap('cs', 'prop'); }),
});

const A = Ember.Object.extend({
  bs: collectionOfInstancesOfB,
  prop: Ember.computed(
    '[email protected].[]',
    function() { flatMap('bs', 'prop'); }),
});

Which would be the right way to do this to avoid the warning?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants